Method and apparatus for determining a list of members for a push to talk communications service

ABSTRACT

A method and apparatus for determining a list of members for a Group Push to Talk Session in a communications network. A Search Proxy function receives, from a requesting network node, a search request message. The search request message comprises at least one of an instruction to limit the maximum time for a search operation to take, an instruction to send search results in segmented blocks, an instruction to send search results in a predetermined format; and an instruction to perform a search according to a predetermined pattern. The Search Proxy function then performs a search for members with which to populate the list and sends the search results to a receiving node. In most cases, the receiving node is the requesting node.

TECHNICAL FIELD

The present invention relates to Push-to-Talk communications services.

BACKGROUND

Walkie-talkie type services are popular amongst users who wish tocommunicate brief messages quickly between one another. Walkie-talkietype services are sometimes known as Push-to-talk (PTT) services.Conventionally, such PTT services have been provided by two-way portableradios which utilise a dedicated part of the radio spectrum, but whichonly allow users to communicate with a small group of pre-selected userswho utilise similar terminals and who are within range of the relativelyshort operating range of the radios. More recently, services have beenintroduced into the United States which piggy-back on the existingcellular telephone infrastructure. However, these services have beenproprietary in nature and have not allowed users to communicate betweendifferent operator networks.

In an attempt to broaden the use of PTT services, an industry groupingknown as the Open Mobile Alliance (www.openmobilealliance.org) has beenestablished with the aim of standardising suitable protocols which willallow inter-network operability for walkie-talkie services offered overcellular networks. The service established by the various standards isknown as Push-to-talk Over cellular (PoC). PoC makes use of the IPMultimedia Subsystem (IMS) to handle the setting up and control of PoCsessions via PoC application servers (acting as SIP ASs). PoC proposesthat associated speech data will be transported over a packet switchedaccess technology. In the case of GSM and UMTS, this will be the GeneralPacket Radio Service (GPRS) access technology. In other networkarchitectures, analogous packet switched access technologies will beutilised for transporting talk data. Push to Talk services may also beoffered over circuit switched access networks, although this is not thepreferred option. The current state of PoC is set out in Release 1.0.The requirements for PoC Release 2 are under discussion. PoC Release 2will extend PoC to include multimedia and not just speech, and alsoinclude a feature that makes it possible to dynamically establish PoCSessions based on location, presence state and interest.

A Dynamic PoC Group Session can be populated with pre-defined Members,or populated by any user, equipped with a PoC capable device (referredto as a PoC Client) fulfilling the location, presence state and interestcriteria. In some cases, a search operation is required in order topopulate the PoC Group Session with members.

The Open Mobile Alliance has defined a Search Proxy to coordinate searchoperations (see OMA-AD-XDM-V2_(—)0-20070724-C), since the searchoperation may require searches in several databases and in differentdomains.

In the event that a search operation is required, the PoC Server sends asearch request to the Search Proxy. The search request includes requiredsearch criteria, and on receipt of the request, the Search Proxycoordinates searches in one or more databases (e.g. there may be morethan one domain to search before a complete result can be returned).Once the search is complete, the Search Proxy sends the results of thesearch to the PoC Server. The results include URIs of PoC Users thatmeet the search criteria. The search results are then used by a functionto evaluate and select PoC User(s) to invite to the Group Session.

If the search criteria are very broad, for example “look for everybodyinterested in football”, the search may take very long time and/orreturn a lot of users fulfilling the search criteria, especially if thesearch is performed over several domains. This may create conflictsbetween limitations in the SIP protocol (e.g. running timers, etc) andthe time it will take to perform the search.

The Search Proxy returns the search result in a single block once thesearch has been completed. The size of the block can be limited byspecifying an optional “max-result” parameter. In this case, the SearchProxy searches until that amount is found or all databases have beensearched without finding any users.

The existing technique for searching for members to invite to a GroupSession is time-consuming, leading to conflicts with SIP requirements.

SUMMARY

The inventors have realised the problems associated with the prior art,and have devised a new search request for sending from a Push to TalkServer to a Search Proxy that refines the searching process and reducesdelays between requesting the search results and obtaining the searchresults.

According to a first aspect of the invention, there is provided a methodof determining a list of members for a Group Push to Talk Session in acommunications network. A Search Proxy function receives from arequesting network node a search request message. The search requestmessage comprises at least one of an instruction to limit a maximum timefor the search operation to take, and an instruction to send the searchresults in segmented blocks. The Search Proxy function then performs asearch for members with which to populate the list, and sends the searchresults to a receiving node. The use of a maximum time limits the time asearch operation can take, making the sending of the search resultsquicker and enhancing a user's experience. Similarly, by sending theresults in segments, rather than waiting for the search to be completed,the receiving node starts to receive search results sooner, enhancingthe user's experience.

Optionally, the receiving node is the requesting network node, althoughit is possible for one node to request the search and another node toreceive the search results.

As an option, where the instruction comprises an instruction to send thesearch results in segmented blocks, the instruction further comprises amaximum size of each segment to be sent.

Optionally, the requesting network node is a Push to Talk Over Cellularserver. However, it is possible for other network nodes, such as InstantMessaging enablers, to request a search.

The requesting network node and the Search Proxy function are optionallylocated in an IP Multimedia Subsystem network, although the invention issuitable for use in other types of network that accommodate Push topTalk services.

The search request message optionally comprises an instruction to returnsearch results according to a predetermined format. This reduces thetime it takes for the receiving node to interpret the search results, asthey can be returned in a format suitable for the receiving node.

The search request message optionally comprises an instruction toperform the search according to a predetermined pattern. In this way,some control can be exercised over which domains etc are searched first.

According to a second aspect of the invention, there is provided amethod of determining a list of members for a Group Push to Talk Sessionin a communications network. A Search Proxy function receives from arequesting network node a search request message. The search requestmessage comprises an instruction to send search results according to apredetermined format. A search is performed for members with which topopulate the list, and the search results are sent to a receiving nodein the instructed format. By sending the results in a format suitablefor the receiving node, less processing power is required at thereceiving node to interpret the results.

The method optionally comprises an instruction to send the searchresults in any one of a predetermined message protocol, and size. Theinstruction optionally comprises one of an instruction to include arandom selection of found members in the search results and aninstruction to include all found members in the search results. Theinstruction optionally further comprises an instruction to order foundmembers in the search results according to any one of an alphabeticalorder, predetermined prioritized users or groups of users first, or anexclusion predetermined users or groups of users.

As an option, the search request message further comprises aninstruction to perform the search according to a predetermined pattern,in order to allow the requesting node to exercise some control overwhich domains are searched first.

According to a third aspect of the invention, there is provided a methodof determining a list of members for a Group Push to Talk Session in acommunications network. A Search Proxy function receives from arequesting network node a search request message, the search requestmessage comprising an instruction to perform the search according to apredetermined pattern. The Search Proxy function performs a search formembers with which to populate the list according to the instruction,and sends the search results to a receiving network node. This is usefulwhere, for example, the requesting node has some knowledge of whichdomains are likely to produce better search results. The instructionoptionally comprises an order in which to search predeterminedinformation sources.

According to a fourth aspect of the invention, there is provided amethod of determining a list of members for a Group Push to Talk Sessionin a communications network. A Search Proxy function receives from arequesting network node a search request message. The search requestmessage comprises at least one of an instruction to limit the maximumtime for a search operation to take, an instruction to send searchresults in segmented blocks, an instruction to send search results in apredetermined format; and an instruction to perform a search accordingto a predetermined pattern. The Search Proxy function then performs asearch for members with which to populate the list and sends the searchresults to a receiving node. These search parameters improve theefficiency of searching and handling the search results.

According to a fifth aspect of the invention, there is provided a SearchProxy for use in a communications network. The search proxy comprises areceiver for receiving from a requesting network node a search requestmessage. The search request message comprises any of an instruction tolimit a maximum time for a search operation to take, an instruction tosend search results in segmented blocks, an instruction to send searchresults in a predetermined format; and an instruction to perform asearch according to a predetermined pattern. The search proxy furthercomprises means for searching at least one database to find potentialmembers for a Group Push to Talk Session, and a transmitter for sendinga search result to a receiving node.

According to a sixth aspect of the invention, there is provided anetwork node for use in a communications network. The node comprises atransmitter for sending, to a Search Proxy function, a search requestmessage. The search request message comprises any of an instruction tolimit the maximum time for a search operation to take, an instruction tosend search results in segmented blocks, an instruction to send searchresults in a predetermined format; and an instruction to perform asearch according to a predetermined pattern. The network node furthercomprises a receiver for receiving a search response message from theSearch Proxy function, the search results comprising a list of potentialmembers for a Group Push to Talk Session. The network node furthercomprises means for populating a list of members on the basis ofinformation contained in the search response message. These searchparameters improve the efficiency of searching and handling the searchresults.

Optionally, the network node is a Push to Talk over Cellular Server.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically in a block diagram a systemarchitecture according to an embodiment of the invention;

FIG. 2 illustrates schematically in a block diagram a signallingsequence to find Users to invite to a Push to Talk Group Sessionaccording to an embodiment of the invention;

FIG. 3 is a flow diagram illustrating the steps according to anembodiment of the invention;

FIG. 4 illustrates schematically in a block diagram a Push to TalkServer according to an embodiment of the invention; and

FIG. 5 illustrates schematically in a block diagram a Search Proxyaccording to an embodiment of the invention.

DETAILED DESCRIPTION

The following description sets forth specific details, such asparticular embodiments, procedures, techniques, etc. for purposes ofexplanation and not limitation. In some instances, detailed descriptionsof well known methods, interfaces, circuits, and devices are omitted soas not obscure the description with unnecessary detail. Moreover,individual blocks are shown in some of the drawings. It will beappreciated that the functions of those blocks may be implemented usingindividual hardware circuits, using software programs and data, inconjunction with a suitably programmed digital microprocessor or generalpurpose computer, using application specific integrated circuitry,and/or using one or more digital signal processors.

FIG. 1 illustrates schematically an IMS network comprising variousnetwork nodes, including application servers and SIP proxies. Thisarchitecture will be well known to those of skill in the art. For thepurpose of this discussion it is sufficient to note that an IMS client1, i.e. a user terminal, is attached to an access network 2 which islikely to be a cellular telephone network such as a GSM or 3G network.Via the access network 2, the IMS client 1 communicates with an IMS corenetwork 3 and with a transport network 4. An IMS service session isestablished by the IMS client 1 exchanging SIP signalling with entitieswithin the IMS core network 3 and with peer IMS clients. The IMS corenetwork 3 is linked to the transport network 4, with the former makingavailable resources within the transport network 4 for use by the IMSclient 1 as required.

Considering further the IMS core network 3, the IMS client is allocateda Serving Call Session Control Function (S-CSCF) 5. The S-CSCF 5 islocated within the home IMS domain of the subscriber using the IMSclient 1, regardless of whether the client 1 accesses the IMS fromwithin the home domain or via a “visited” domain. The CSCFs (includingthe S-CSCF 5) handle reachability, authentication and authorisationfunctions in respect of subscribers. Provision of services is handled bySIP Application Servers (ASs). FIG. 1 illustrates a PoC AS 6 whichprovides the service logic for the PoC service.

When a user wishes to establish a Group Session, and wishes to populatea list of members for the Group Session, the PoC AS 6 contacts a SearchProxy 7, which in turn contacts at least one database 8, and returns alist of potential group members to the PoC AS 6. The PoC AS can thenselect which members of the list to invite to the group session.

When the PoC AS 6 sends a search request to the Search Proxy 7, the PoCAS 6 includes in the request one or more of the following parameters:

-   -   A Search Timer indicating the maximum time the search operation        is allowed to take before the Search Proxy must return a result;    -   A Max result value. The Max result value can be limited by        setting a <max-participant-count> element in the Group document,        making it possible to limit the number of returned URIs to a        reasonable value;    -   One or more search patterns. Search patterns are used to target        domains, the search order for searching different target        domains, users, groups and other search sources;    -   A Search Response instruction that requests that the search        results are returned having a certain size or structure; and    -   A request for Segmented Results, making it possible for the PoC        AS 6 to receive parts of the result before the search operation        is completed. This may further include an instruction limiting        the size of each segment.

Once the Search Proxy 6 has received the search results, it begins thesearch process taking the Search Timer, the existing Max-result, SearchPattern, Segmented Result and/or Search response into account.

Possible search results include:

1. Positive response: A list of URIs is returned and the search iscompleted (HTTP 200 OK response).

2. Positive response: A list of URIs is returned and the searchoperation continues as a result of a request for response segmentation(HTTP 200 OK response).

3. Negative response: No PoC User fulfilling the search criteria isfound (HTTP 404 Not Found response).

4. Negative response: search timer expires (HTTP 404 Not Foundresponse).

5. Negative response: search request is in conflict with the networke.g. when search tree or domain is not recognized, or search expressionis not allowed (e.g. HTTP 409 Conflict response).

The Search Timer, Max-result, Search Pattern, Search response and/orSegmented Result can be either defined in a Group document for theDynamic Group in a Shared Group XDMS or as system configurationparameter in the PoC Server, or a combination of both. A Shared GroupXDMS is a database for storing Group documents to provide multipleservices access to Group documents, and Group documents include rulesfor a particular group. A Group document may contain Dynamic Group rulesfor more than one service. Dynamic PoC Groups documents include rulesfor Dynamic PoC Groups. Rules are syntactically organised according toXML schema(s). Each document has at least one schema. The word rules isused herein to refer to parameters that apply to all members and for allservices using the Group, and may consist of, for example, parametersvalid only for a specific service, or a specific user.

The search timer may be derived from SIP protocol timers, the Groupdocument or configuration in the PoC Server, and provides a limit on themaximum time that the search can take.

It is possible to use parameter “max-participant-count”, defined as anelement in the Dynamic Group document, (as specified in OMA spec “SharedGroup XDM Specification”, Version 1.0, Open Mobile Alliance™) and/or asa system configuration parameter, as an input for setting the value ofexisting parameter “max-result”.

Search patterns can be defined by setting, for example, a Domain SearchOrder. Listing domains in a certain order can be used to specify searchorder. Furthermore, a search pattern can be defined by setting a searchorder between static data (stored in XDMSs) and dynamic data (ServiceEnabler).

The Search response can be influenced by setting any of the followingattributes:

Search Type: Values are selected from one of “Random” (the users arerandomly selected), “All” (all users are returned, max-result not used),and “Ordered”. Where the results are Ordered, examples of values are:

1. A-first (default). A-first is according alphabetical order on forexample first name, last name, interest profile data.

2. Not included users, groups, lists or profile data. For example userid (SIP URI), first name, last name, interest profile data.

3. Prioritized users first. For example user id (SIP URI), first name,last name, interest profile data.

In order to reduce delays, the PoC Server may request the result to besegmented rather than sent in a complete block. A segmented sequence ofresponse requires either a session based search with session ID andrepeated HTTP/POST requests with the unique session ID (ID is defined bythe PoC Server), or can be done using a single HTTP/POST requestrequesting the Search Proxy to transfer the result in segments where themax number of Users transferred in each segment is according to aparameter set by the PoC Server.

Note that most of the search parameters described above are not mutuallyexclusive, so, for example, a search request may instruct a maximum timein addition to a request for segmented results and a request to send theresults in a particular format with prioritized user first, arrangedalphabetically.

An example of a signalling sequence for requesting a search by a SearchProxy is illustrated schematically in FIG. 2. In this example, thepre-arranged PoC Group includes only dynamic criteria for PoC Users tobe invited.

The steps of the flow are as follows:

S1. The PoC Client 1 initiates a Pre-arranged PoC Group Session bysending a SIP INVITE request to the PoC Server 6.

S2. The Pre-arranged PoC Group document is fetched by the PoC Serverfrom the Shared Group XDMS 9.

S3. The PoC Server detects that there is a need to perform a searchusing the Search Proxy. The PoC Server 6 includes Search Timer,Max-results, Search Pattern, Search Response and Segmented result andsends a HTTP POST request to the Search Proxy 7.

S4. The Search Proxy 7 starts the search in a Shared XDMS/PresenceServer 10 of the Domain A. The Search proxy 7 supervises the time ittakes to do the search, and the number of results received, based on theSearch Timer and Max-results received in the HTTP POST request from thePoC Server 6.

S5. When the search has resulted in Users found in the Domain A, and ifthere is still time to do more searches, and if Max-results is not yetexceeded, the Search Proxy 7 returns the results so far to the PoCServer 6 in a HTTP 200 OK response. The response includes the resultsand the state of the search operation e.g. elapsed time. If the searchwas requested with a segmented result, the response is followed by alist of Users in a sequence of messages.

S6. The PoC Server invites the PoC Users in the list received in theHTTP 200 OK response and its subsequent messages as they are received.

S7. The Search Proxy continues the search, now in domain X, based on theinformation received in the HTTP POST request.

S8. When the search is complete, the results are returned to the PoCServer 6 and PoC Users found in the Domain X are invited to the GroupSession. If the search was requested with segmented results, bodies witha list of Users found in Domain X are returned in a sequence ofmessages, and the PoC Server 6 invites found PoC Users in the same wayas described above.

S9. When there are no more results to return, the Search Proxy 7 sends amessage with end indication to the PoC Server.

Note that the PoC Server 6 may need to perform the search several timesduring a PoC Session in order to re-evaluate the Dynamic rules.

FIG. 3 herein is a flow diagram illustrating the steps according to anembodiment of the invention. The following numbering refers to thenumbering of FIG. 3:

S1. The requesting node generates a request for search. The searchincludes at least one additional instruction, selected from a maximumtime for the search to take, and instruction to send the search resultsin segments, an instruction to send the search results in a particularformat, and an instruction to search in a predetermined pattern, asdescribed above;

S2. The requesting node sends the search request to the search proxy;

S3. On receiving the search request, the search proxy performs thesearch according to the additional instructions;

S4 Once the search is complete, the search proxy sends the searchresults to a receiving node (in most cases the receiving node is therequesting node) according to the instructions.

Referring to FIG. 4 herein, there is illustrated a Push to Talk Server11, such as a PoC Server. The Server comprises a transmitter 12 forsending the search request to the search Proxy, and a receiver 13 forreceiving a search response message from the Search Proxy function. TheServer also comprises a processor 14 for generating the search requestmessage and for populating a list of members on the basis of informationcontained in the search response message. The Server may comprise amemory 15 for storing the results contained in the search responsemessage.

Referring to FIG. 5 herein, there is illustrated a Search Proxy 16. TheSearch Proxy comprises a receiver 17 for receiving a search requestmessage from a Push to Talk Server. A processor 18 is provided forperforming the search in the basis of instructions contained within thesearch request message. A memory 19 may be provided for storing orcaching the results of searches, and a transmitter 20 is provided forreturning a search response to the Push to Talk Server.

The invention as described above allows the PoC Server to control thesearch operation, keeping the search time below SIP protocol timers.Furthermore, it enables the Group document to control the searchoperation. The PoC User can control the results of a search operationby, for example, setting the search rules in the Group document, if theuser is authorized to do so. Currently, a user must be the owner of thedocument in order to set the search rules, although it is envisaged thatthere may be circumstances where it would be desirable for a non-ownerof the document to be allowed to set the search rules. A searchoperation may be limited to predefined domains, and it is possible toinitiate establishment of a PoC Session without waiting for the searchoperation to be completed.

Although various embodiments have been shown and described in detail,the claims are not limited to any particular embodiment or example. Noneof the above description should be read as implying that any particularelement, step, or function is essential such that it must be included inthe claims' scope. For example, the above description describes ascenario in which the originator of the search request is the PoCServer. However, other service specific servers may also use the searchparameters according to the invention. For example, an Instant Messaging(IM) enabler server may make use of the invention to populate a group ofmembers to whom a message should be send. A converged IP Messagingenabler server may make a similar use of the invention.

The following acronyms are used in this specification:

-   AS Application Server-   IMS IP Multimedia Subsystem-   OMA Open Mobile Alliance-   PoC Push To Talk Over Cellular-   PTT Push to Talk-   SIP Session Initiation Protocol-   URI Uniform Resource Identifiers-   XDM XML Data Management

The invention claimed is:
 1. A method of determining a list of membersfor a Group Push to Talk Session in a communications network that uses aSession Initiation Protocol, the method comprising: at a Search Proxyfunction, receiving from a requesting network node a search requestmessage, the search request message comprising at least fourinstructions, the instructions comprising: an instruction to limit amaximum time for a search operation; an instruction to send searchresults in segmented blocks; an instruction to return the search resultsaccording to a predetermined format, such that found members are orderedin the search results according to any one of alphabetical order,predetermined prioritized users or groups of users, and an exclusionpredetermined users or groups of users; and an instruction to performthe search according to a predetermined pattern; performing a search formembers with which to populate the list according to the at least fourinstructions included in the search request message; and sending thesearch results, from each domain that is searched, in segmented blocksto a receiving node before the maximum time at the search proxy functionexpires.
 2. The method according to claim 1, wherein the receiving nodeis the requesting network node.
 3. The method according to claim 1,wherein the instruction to send the search results in segmented blockscomprises a maximum size of each segmented block to be sent.
 4. Themethod according to claim 1, wherein the requesting network node is aPush to Talk over Cellular server.
 5. The method according to claim 1,wherein the requesting network node and the Search Proxy function arelocated in an IP Multimedia Subsystem network.
 6. The method accordingto claim 1, wherein the instruction further comprises an instruction tosend the search results in any one of a predetermined message protocoland size.
 7. The method according to claim 1, wherein the search requestmessage further comprises one of an instruction to include a randomselection of found members in the search results and an instruction toinclude all found members in the search results.
 8. The method accordingto claim 1, wherein the predetermined pattern comprises an order inwhich to search predetermined information sources.
 9. A Search Proxy foruse in a communications network that uses a Session Initiation Protocol,the search proxy comprising: a receiver for receiving from a requestingnetwork node a search request message, the search request messagecomprising at least four instructions, the instructions comprising: aninstruction to limit a maximum time for a search operation, aninstruction to send search results in segmented blocks, an instructionto send search results in a predetermined format, such that foundmembers are ordered in the search results according to any one ofalphabetical order, predetermined prioritized users or groups of users,and an exclusion predetermined users or groups of users; and aninstruction to perform a search according to a predetermined pattern; aprocessor for searching at least one database to find potential membersfor a Group Push to Talk Session according to the at least fourinstructions included in the search request message; and a transmitterfor sending the search results, from each domain that is searched, insegmented blocks to a receiving node before the maximum time at thesearch proxy function expires.
 10. A network node for use in acommunications network that uses a Session Initiation Protocol, the nodecomprising: a transmitter for sending, to a Search Proxy function, asearch request message, the search request message comprising at leastfour instructions, the instructions comprising: an instruction to limita maximum time for a search operation; an instruction to send searchresults in segmented blocks; an instruction to return the search resultsaccording to a predetermined format, such that found members are orderedin the search results according to any one of alphabetical order,predetermined prioritized users or groups of users, and an exclusionpredetermined users or groups of users; and an instruction to performthe search according to a predetermined pattern; a receiver forreceiving, before the maximum time at the search proxy function expires,a search response message from the Search Proxy function comprisingsearch results with a list of potential members for a Group Push to TalkSession; and a processor for populating a list of members on the basisof information contained in the search response message.
 11. The networknode according to claim 10, wherein the network node is a Push to Talkover Cellular Server.